建立專案之前，環境設置與程式碼的版本控制，是很重要的環節。對於要建立難以維護的專案也是如此。

下面我們來聊聊怎麼透過環境設置與版控，讓專案難以維護。

環境設置

口耳相傳的環境設置

不以程式或文件的形式，來處理環境設置。這樣一來，環境設置的方式就只有經手過的人才會知道怎麼做。

下一個要維護的工程必須要從建制環境開始，這可以大幅的減緩他處理問題的速度，是一個很好的開始。

docker

如果團隊使用 docker 環境開發，在建立了 docker container 之後，如果環境不符合你程式的需求，比方說缺少某個套件的話，直接進入 container 裡面修改環境。

這樣，如果有人重開 docker container，他將會發現原本可以運作的程式跑不了了，並花上好幾個小時的時間處理這個問題。

如果有人請你修改 DockerFile，提出環境設置不是工程部門的職責，並婉轉地回拒這個要求。

版本控制

不做版控

對現今的專案來說，做版控是很基本的一件事，大多專案都會要求要有某種版控系統。

幸運的是，對小型公司來說，你還是有機會遇到不做版控的專案。堅持不做版控可以保證專案的問題難以找到原因，也對未來撰寫難以維護的專案提供了很好的基礎。

不過大多時候，專案還是會有既有的版控系統。這時我們就必須用上其他技巧。

git message

將心力專注在開發新功能上，不要浪費時間構思 git commit message。

建議可以使用以下幾個 message：

• WIP
• doing
• a
• （全型空白）

user.name

作為工程師，上班期間內所有程式碼都是公司的財產，我們不應該對自己撰寫的程式碼居功。

所以，記得將 user.name 改成公司名稱，user.email 改成公司客服的信箱。如此一來，當程式碼有問題時，維護的工程師就能從 git commit 的資訊裡，正確地找到該負責的對象：公司的客服部。

git-flow-ish

參考 git-flow 或 github-flow 的做法，但是不要完全的依照其指導來做。

這樣一來，每當新進人員要處理版控問題時，他就必須在看似 git-flow 的 branch 裡面，再特別研究那些不是 git-flow 會出現的 branch 以及做法。可以確保在版控議題上，我們又拖累了一點他維護的進度。

延長 branch 的生命週期

在 git 上面，要開一個新的 branch 實屬不易。所以，我們應該盡可能地延長他的生命。

持續在單一 branch 上面撰寫新功能，並不斷從上面合併進開發主幹。這樣一來，如果版控需要調整，解決衝突將會是一場大戰，從而避免了任何讓版控更好的調整。

如果有人開始抱怨，嘗試將問題歸咎於版控系統，說不定可以成功說服大家不用版控。

merge conflict

每個工程師都很忙，而且開發時有所謂的「心流」，開發時期不應該打擾他們。

所以，合併衝突時就自己一個人解決。可以根據自己對業務理解的邏輯，判斷這些衝突該怎麼解決。

如果不小心誤刪別人的程式碼，不用擔心，版本控制上面都會保有過去的程式碼，他們自己會想辦法處理好的。

hotfix

如同前面所說的，工程師最大的作用，就是撰寫客戶需要的功能，滿足客戶的需求。

所以，當客戶提出需求，不管這個需求是不是「很急」，可以從 master 拉一個 hotfix branch 以緊急上線的做法來趕工這個需求。

如此一來，你就不需要經歷合併到 develop 測試的漫長過程，可以直接著手開發。

功能上線之後，就趕快著手下一個功能的開發了，不要花時間將 hotfix 合併進 develop，這應該是下一位要將 develop 合併進 master 的工程師來處理。相信他看到 master 上面有 develop 還不存在的新功能，一定會知道這是快速提供客戶需求所產生的結果，並能在解決衝突的過程同時保留雙方的功能而不出錯。

至於合併的問題該怎麼處理，請參考這個原則：先合併到 master 的先贏，後合併的負責解衝突。

遠端同步

如果無法 push 到遠端主機，git push -f 可以解決所有的問題。